@microsoft-github-policy-service agree

CC @stuartleeks

This is also needed for actions/attest-build-provenance

Ok I'm running into a little issue. If platform is specified as an input, then the image is output as type=oci,dest=/tmp/output.tar, and can't be found by docker inspect to get the digest.

Would anything break if I moved loading the tar from the runPost to the main script? Will try it out, but warn me of potential pitfalls pls

Ok, this is ready for review again. I have a sample workflow successfully working end-to-end (unfortunately in a private repo). The key change I made was coping the oci tar to docker at the end of the build, in addition to the beginning of the post-run step. I need extra review on whether thats ok, and whether I can safely remove the copy from the start of the post-run step.

@chrmarti Can you help this?

Interesting, I've actually found a bug after using this for a couple months:

  [2025-08-13T21:47:09.511Z] #29 preparing layers for inline cache 0.0s done
  #29 exporting manifest sha256:7c8bbc48346568b7e353dc05a27da65dbf59be09aaca288ac227fd75aaa8a90c 0.0s done
  #29 exporting config sha256:a90b3d4cc33c5a602d174bbb594cdc2cc03a0c7a37c0af8830d17d9452c7f235 0.0s done
  #29 sending tarball
  
  
  [2025-08-13T21:47:14.123Z] #29 sending tarball 4.8s done
  #29 DONE 5.0s
  
  
📌 Copying image...
📌 Copying image...
Images: moby/buildkit:buildx-stable-1

Image digest for linux/arm64: sha256:4356f32534b35ab32c4a0690f02a43a2ad86e89e317ddab327ecd205daae8aa0

Somewhere between the build completing and the digest output, the digest is getting "confused". The second digest in the logs above (sha256:4356f3253) is for the amd64 platform which is pushed from a parallel job, not the arm64 digest built in this job (sha256:7c8bbc48346568b7)